CU Amiga Super CD-ROM 2/CU Amiga Magazine's Super CD-ROM 02 (1996)(EMAP Images)(GB)[!][issue 1996-04].iso/magazine/amiga_e/amigae.july.archive/000034_crash!mars.let.uva.nl!wouter_Fri, 16 Jul 93 15:51:34 PST.msg

Text File | 1993-08-31 | 6KB | 132 lines

Received: by bkhouse.cts.com (V1.16/Amiga)
    id AA00000; Fri, 16 Jul 93 15:51:34 PST
Received: from mars.let.uva.nl by crash.cts.com with smtp
    (Smail3.1.28.1 #15) id m0oGxkR-0000A0C; Fri, 16 Jul 93 14:55 PDT
Received: by mars.let.uva.nl id AA16092
  (5.65c/IDA-1.4.4 for [e-mail]); Fri, 16 Jul 1993 23:58:58 +0200
Return-Path: <[e-mail]>
Date: Fri, 16 Jul 1993 23:58:58 +0200
Message-Id: <[e-mail]>
X-Organisation: Department of Computational Linguistics,
                University of Amsterdam
                Spuistraat 134, 1012 VB Amsterdam, The Netherlands
From: Wouter van Oortmerssen <[e-mail]>
To: [e-mail]
Subject: Optimizing E

>> Boyerm.e probably suffered from a low buffer size input, which reminds me,
>> what are the proper arguments for the DOS function SetVBuf()? The DOS
>> manual says it accepts 4 arguments, E only accepts 3!?

SetVBuf() is broken in 2.1b. If you really need to use this function,
the only thing you can do is write an assembly stub for this yourself

>> Okay, so the boyerm.e example wasn't a very good as it relied on DOS calls,
>> but I still say E is slower and would benefit from a good optimizer. While
>> I was debugging my programs, I noticed that E always(?) used MOVE.L x(A5),D0
>> for variable storage/retrieval. In a tight loop, a MOVE.L x(AN),D0
>> will cost more cycle time than a MOVE.L D1,D0. Since E doesn't touch the
>> other data registers often, it would help speed time greatly if you could
>> use them.

already very early in the design stage of the E compiler, I had to make
a choice: do I give the registers to the language, or do I make them
free for use with inline assembly? back then, I was just making the perfect
language for just one person (me), and since I enjoy using assembly
very much, I chose for the latter. The consequence is that the compiler
_may_ thrash registers with every expression, and the fact that they
don't most of of the time is no guarantee for the compiler that it can
put it's variables there.

>> For a better example(?) I coded the following short |ittle program, which is
>> small and relies on no external calls (except for outputting of result at
>> the end which btw, if left out under SAS/C, makes the program run under
>> 1 sec - clever optimiser :)

yeah, but you give it something any optimizer could get away with. Try
again with a more complex (real-life) algorithm with more variables in certain
parts than registers, consisting of multiple functions (i.e. own written
functions, not buitins etc.), and the gains made from the optimizer will
drop down tremendously.

>> Although I don't expect E to outperform a commercial C product, using
>> spare data registers would increase E's performance tremendously.

agreed. SAS/C can outperform E 2.1b when it wants to, in most situations.
the problems due to the nature of compiler and language regarding
allocating registers and such, will not stop me from gradually enhancing
EC with capabilities that allow great optimisations in code. some
of you will probably notice that v2.5 will already be a great step
forward, and it will continue to be enhanced to generate even better
code, making good use of registers (which will cause performance
tradeoffs with inline assembly, but nothing serious).

>> One last suggestion.. how about making some E functions (such as WriteF)
>> more assembling friendly, so you can use certain E functions in the middle
>> of an assembly code? ie. it uses only the upper data/address registers (4-7)
>> and leaves the lower ones intact.

it would be very future-incompatible to guarantee certain registers
preserved by certain E language constructs.
I of course simply could have saved all registers at any swap
between E and Asm, but this would have been unnecessary overhead.
most inline assembly parts simply take a few values, do some
heavy computing, and shove the result in an E variable, and thus
won't need to save _any_ registers. that's why you have to do
it yourself. a better programming style if you want to mix E
and Asm all the time, is to keep all long term values that
have to be preserved in E variables, and use registers for
all other variables that "live" only within one block of
assembly.

>> Regards..
>> Son Le
>>
>> PS. Wouter, your address <[e-mail]> bounced.

oh? are you the only one having trouble with this? I still receive
plenty of mail there.

>> > >what are the proper arguments for the DOS function SetVBuf()? The DOS
>> > >manual says it accepts 4 arguments, E only accepts 3!?
>> >
>> > I remember you asking this before.  Don't know, so I didn't answer.
>>
>> I was hoping Wouter could answer this for me. He properly missed the last one


I did miss it. I was on a short vacation.

>> > I recall Wouter saying that ++ returns a value and eats up some ticks in th

>> > process.  That may be what's going on in that Asm instruction you questione
,
>> > the value is being returned in D0.  The C compiler sees that you're not doi
g
>> > anything with the returned value, so optimizes it away.

that's exactly what happens. E v2.5 too takes care of this.

>> >Did Wouter say that the new version can output debug symbols?
>>
>> I don't recall mention of it.  But now would be a good opportunity. :)

yes it does. works great with any disassembler/debugger/profiler etc.

>> BTW (Wouter), is A6 free for our use in E?  Should we be saving and restoring

>> A0-A3,A6 .vs. only A0-A3?

a6 is free, yes. only a4/a5 must be preserved.
if you use a6 in inline assembly and want it to preserved until after
an E statement, you'll have to save it on the stack too.

>> Later.  -- Barry
>>

Wouter

   ____  Wouter van Oortmerssen, [e-mail]
  / __/  "Einen Satz verstehen, heisst, wissen was der Fall ist,
 / __/    wenn er wahr ist" - Wittgenstein
/___/  ->subscribe to the E mailing list: [e-mail]<-